The present invention relates to the field of computers and more particularly to multiprocessor systems having CPUs that can be pooled for system operation.
Large-scale modern data processing systems have an architecture that embodies multiple CPUs that are closely integrated to form multiprocessor systems. The CPUs in such multiprocessor systems operate under control of an Operating System. Large scale operating systems include OS/390, VM/ESA, UTS, VSE/ESA and TPF. Some multiprocessors are well-known to be have domains where each domain is assigned one instance of one operating system and is started with an IPL (initial program load) of that operating system. More than one operating system, which can be different operating systems or different instances of the same operating system, run in the multiple domains of the multiprocessor system, one operating system per domain. A feature of domains enables one or more logical processors (LPs) to be established for each domain. A logical processor is a logical entity that the operating system creates, controls and assigns to programs, frequently called independent software vendor (ISV) programs, such that each program interprets the assigned LP as its own xe2x80x9cvirtual CPUxe2x80x9d. The actual functioning of the LP may be on a single one of the multiple CPUs in the multiprocessor system or may be distributed across multiple ones of the CPUs on a time-shared basis with other LPs.
Computer users are concerned about the cost and availability of their computer systems and particularly upgrades and downgrades in the CPU configuration. A CPU upgrade is performed, among other reasons, to increase the capacity of the computer system and a CPU downgrade is performed to reduce the capacity of the system. Increasing or decreasing the capacity of a system, besides tailoring the system to fit the data processing needs of the user, also has a significant cost element since many software products that run on computer systems are frequently priced to the user as a function of the system capacity and the CPU configuration.
Typically, software licensing costs are computed based on the number of CPUs that are available to run operating systems and Independent Software Vendors (ISVs) software in the full system. In general, the software licensing costs have been charged based upon the total number of available CPUs in the full multiprocessor system since generally all such CPUs have been available to run the installed software if called upon to do so under user election and control.
In large multiprocessor computer systems that employ multiple system control programs (SCPs), CPU upgrades have been difficult to schedule because the computer user must plan an outage for all of the SCPs running on the CPU to be upgraded. With the continued exploitation of logical partitioning using multiple domain features (MDF), it has become impractical to schedule all SCPs to be down at the same time. This difficulty causes customers to delay necessary upgrades rather than attempting to schedule the full system outage. The current upgrade process includes the following steps:
1. Establish a hardware upgrade price with the hardware vendor.
2. Notify the Operating System Vendor (for example, IBM for main frame systems) to change their software charges to account for the upgraded system capacity.
3. Notify Independent Software Vendors (ISVs) to change their software charges to account for the upgraded system capacity and providing the new CPUID version code when necessary.
4. Update ISV software encoded CPUID tables.
5. Take a system outage to implement the upgrade.
Steps 1-4 are normally performed days or even weeks before the outage is taken. While few software products actually check the CPUID version code for compliance, the customer is normally required by contract to notify both the Operating System vendor and any ISVs when their licensed software will be run on a different hardware configuration. The current practice often encounters delays that are wasteful to the computer user.
The above-identified cross-referenced application describes a multiprocessor system having a plurality of CPUs that can be dynamically reconfigured between online and offline without system shutdown. The multiprocessor system is operable in different modes, including a user mode for processing user programs and a system mode for processing system programs unavailable to users. Although the dynamic reconfiguration of that cross-referenced application makes moving CPUs between online and offline modes easy, the problem still remains of isolating ISV, OS or other programs from user control such that reductions in software fees below those charged for all CPUs in the full multiprocessor configuration might be obtained.
Accordingly, and in light of the problems of prior systems, there is a need to be able to isolate programs to certain selected ones of the CPUs in a multiprocessor system and to upgrade computer CPU configurations dynamically without causing the computer user to suffer the delays and outages that have heretofore been required. It is desirable that users be able to purchase additional capacity quickly and with little effort.
The present invention is a multiprocessor system having a plurality of CPUs that are configured into different servers. The present invention partitions the total number of available CPUs into one or more smaller pools of CPUs called servers where the number of CPUs available to a server is reduced below the total number of available CPUs. Software licensing costs are thereby reduced because the number of CPUs available to run the operating system or ISV software has been reduced to the number of CPUs in the pool of the server rather than the total number of available CPUs in the multiprocessor system.
In order to enforce the isolation of CPUs required by software licensing, separate identification codes, CPUIDs, that contain unique system serial numbers are assigned to each server in the multiprocessing system. A CPUID typically includes a version code which identifies the number of CPUs allocated to the server and a unique system serial number for the server. The multiprocessor system has multiple CPUIDs, one for each server (each pool of CPUs that can execute operating systems and ISV software).
The multiprocessor system supports pools of CPUs of different types including, for example, servers, spares and coupling control pools. Of these types of pools, only the servers are assigned operating systems and ISV software on which software licensing costs are computed. Generally, a CPU that is assigned to run Coupling Control Code (CCC) is not in a server pool and can be excluded from licensing fees. Similarly, spare CPUs are not members of any server pool and can be excluded from licensing fees. Spare CPUs are available to replace CPUs in any pool. The number of CPUs assigned. to the different pools is under feature control where feature control is a facility for controlling features of the multiprocessor system. The feature control facility is not accessible by end users of the multiprocessor system. CPU pool assignment for each domain is done by the Presentation Element Platform (PEP) and is not viewable from the Hardware Management Console (HMC). The type of operating system permitted to run in a CPU pool is also under feature control.
The multiprocessor system can switch between online and offline without system shutdown. The multiprocessor system is operable in different modes, including a user mode for processing user programs and a system mode for processing system programs unavailable to users. Although the multiprocessor system is capable of being shutdown to terminate operation and permit reconfiguration during or after a shutdown, the multiprocessor system of the present invention includes a dynamic reconfiguration subsystem for reconfiguration without shutdown.
The dynamic reconfiguration subsystem includes a service processor having a feature file for identifying a current online number corresponding to a current number of online CPUs, a current offline number corresponding to a current number of offline CPUs and an update number corresponding to changes to be made in the current online number and the current offine number. A reconfiguration control unit is provided for reconfiguring CPUs in the multiprocessor system without being shutdown that includes a store for storing configuration code in response to the feature file, a system state execution unit for executing the configuration code to form configuration control information and decoder means for decoding the control information to change the current number of online CPUs and the current number of offline CPUs by the update number.
The present invention allows the definition of offline logical processors (LPs) which may be brought online when the reserved capacity is made available. The total number of domain LPs, including offline LPs, may not exceed the total number of physically installed CPUs. However, when the domain is activated, the number of online LPs per domain may not exceed the number of customer purchased non-coupling control CPUs.
The actual upgrade process is controlled to return the correct CPUID including version code to the SCP when it is retrieved with the Store CPUID (STIDP) instruction.
During SCP initialization, a STIDP instruction is performed to retrieve the CPUID and save it in storage. IBM SCPs such as OS/390 use this storage location to establish a unique dynamic path array identifier, determine recovery actions, and establish future Service Call Logical Processor (SCLP) actions. ISV software products (in particular those products that check their encoded CPUID tables for compliance) issue their own STIDP when that ISV software is initialized.
The CPUID contains each vendor""s model number (for example, Amdahl 700) as well as a version code which identifies a specific server (for example, xxe2x80x258xe2x80x2=785). In the case of the Amdahl MGS 700, the Xxe2x80x25xe2x80x2 indicates that the CPUs are running at full speed and the Xxe2x80x28xe2x80x2 defines that eight physical CPUs are installed and available for customer use.
The foregoing and other objects, features and advantages of the invention will be apparent from the following detailed description in conjunction with the drawings.